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reasonable expectation of success. Finally, the prior art reference (or 
references when combined) must teach or suggest all the claim limitations. 

As will be demonstrated in the following, the Texier and Schultz references, when 
combined, do not teach or suggest all of the limitations of Applicant's single independent 
claim 1, and consequently, Examiner has not established the prima facie case required for 
the rejection. 

What Applicant's claim 1 sets forth 

An embodiment of the "graphical user interface" to which Applicant's claim 1 is directed 
is shown in FIG. 13 and described beginning at page 48, line 15. To further Examiner's 
understanding of claim 1, reference numbers from FIG. 13 have been added to the claim 
as amended in Applicants' response of 1/24/05: 



1 1. (previously presented) A graphical user interface for specifying an 

2 action to be performed on a field of a record stored in a memory device 

3 when a query with which the action is associated returns the record, the 

4 query being executed on a processor that has access to the memory device 

5 and interacts with the graphical user interface, 

6 the graphical user interface comprising: 

7 a window (1301) containing a table wherein the field of the record 

8 has an entry (1302) that is selectable by the user, the entry including 

9 a fu-st field (1303) of the entry that identifies the field of the 

10 record to be acted on; and 

1 1 one or more action fields (1307) of the entry that, when the 

12 user has selected the entry, the user may set to specify the action. 



The following limitations of claim 1 are particularly pertinent to the present discussion: 

• there is an entry in the table for a field of a record on which an action is to be 
performed when a query with which the action is associated returns the record; 

• the entry has a first field that identifies the field of the record to be acted on; and 

• the entry has one or more action fields that the user may set to specify the action. 
Examiner explains his rejection of claim 1 at page 3 of his final rejection. The basis of 
the rejection is Texier's FIG. 1. For purposes of the present discussion, there are two 
windows that are of interest in FIG. 1 : the window labeled DATA BASE and the window 
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labeled EMPLOYEE INFORMATION. The DATA BASE window includes a menu 

labeled BASE FILE which permits the user of the GUI of FIG. 1 to select an operation 

to be performed on the database represented by the DATA BASE window. The 

EMPLOYEE INFORMATION window serves to read data from or write data to the 

database. Examiner reads claim Ts "table" onto FIG. I's EMPLOYEE INFORMATION 

window and then treats the BASE FILE menu as specifying both the action to be 

performed and the "first field of the entry that identifies the field of the record to be acted 

on". An additional difficulty with this reading is that the BASE FILE menu is not, as 

required by the claim, part of the entry in EMPLOYEE INFORMATION. Further 

difiiculties become apparent when the description of FIG. 1 at col. 6, lines 12-23 of 

Texier is considered: 

FIG. 1 also shows the visual display of two forms generated by the method 
of the invention. These two forms are entirely independent, though used in 
the present case for the same user-application, namely a data- base 
management system. The first form realized in the window denoted "Data 
base" allows carrying out a temporary menu, ie the "Base file" regarding 
the operations on the data base file. The second form realized by the 
window denoted "Employee information" concerns an acquisition/display 
mask for a particular recording of the data base file. 

It is clear fi-om this description that EMPLOYEE INFORMATION is simply a screen in 
which data may be input to or read from fields of a record in the DATA BASE, depending 
on the menu selection in the BASE FILE window. LAST NAME:, FIRST NAME:, 
etc. are labels in the screen, not field names, and the contents of the fields in EMPLOYEE 
INFORMATION are neither the names of fields in records nor actions to be performed on 
the named fields, as required by claim 1. 

In his rejection. Examiner relies on Schultz for the claim limitation "one or more action 
fields (1307) of the entry". As should be clear fi-om the above discussion, Texier does 
not disclose a table in a window in which the entries have the names of fields in records; 
consequently, even if Schultz did disclose the limitation "one or more action fields of the 
entry", the combination of Texier with Schultz cannot show all of the limitations of the 
claim and Examiner has not made his prima facie case. 
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Schultz, however, does not disclose that limitation. Examiner cites FIG. 5 and col. 3, 

lines 11-16 of Schultz for "one or more action fields of the entry". Col. 3, lines 11-16 

read in their entirety as follows: 

Thus, it is another object of the invention to provide a method of 
monitoring the operation of a control program that provides accurate 
indications of the timing of the execution of parts of the control program 
such as will avoid the problems of asynchronous operation of the display 
and that will permit troubleshooting of control programs that operate faster 
than may be perceived by the human eye. 

There is certainly nothing in the above-cited location that has anything at all to do with 
the claim limitation "one or more action fields of the entry". 



The situation is not much better with regard to FIG. 5. FIG. 5 is described in Schultz as 

"a task scheduling table providing information entered by the user for scheduling the 

tasks to make best use of the processor resources" (col. 4, lines 1-3), but the table 88 of 

FIG. 5 is not part of Schultz' s user interface. Users may enter data for the table, but all 

that Schultz discloses about the user interface for so doing is the following: 

Referring now to FIGS. 1 and 5, data defining each task 80 may be entered 
by the programmer through the programming terminal 19, or other 
terminal such as a microprocessor based computer, based on the 
programmer's knowledge of the overall operation of the controlled 
equipment 22 and the particular tasks and their criticality. This data is 
received by a task scheduling table 88 and used by the task control blocks 
85. (col. 7, lines 37-44) 

At this location, too, there is nothing concerning "one or more action fields of the entry". 

In Examiner's Response to Arguments at page 15 of his OflSce action of 6/2/05, Examiner 
deals with the fact that Schultz's FIG. 5 is not a GUI as follows: ". . . the Office has cited 
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